home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19960715-19961006 / 000095_news@columbia.edu _Sun Jul 28 21:24:34 1996.msg < prev    next >
Internet Message Format  |  1996-11-03  |  4KB
  1. Return-Path: news@columbia.edu
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id VAA07073 for <kermit.misc@watsun.cc.columbia.edu>; Sun, 28 Jul 1996 21:24:33 -0400 (EDT)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id VAA09302 for kermit.misc@watsun; Sun, 28 Jul 1996 21:24:32 -0400 (EDT)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc,comp.dcom.modems
  7. Subject: Re: Problem getting 28800 bps in C-Kermit 5A(190) on a v.34 internal
  8. Date: 29 Jul 1996 01:24:11 GMT
  9. Organization: Columbia University
  10. Lines: 55
  11. Message-ID: <4th3rr$k91@apakabar.cc.columbia.edu>
  12. References: <CROTEN.96Jul24005129@crl.crl.com> <CROTEN.96Jul27022451@crl.crl.com> <1996Jul28.193939.943@ia-us.com> <CROTEN.96Jul28153957@crl.crl.com>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14. Xref: news.columbia.edu comp.protocols.kermit.misc:5667 comp.dcom.modems:145925
  15.  
  16. In article <CROTEN.96Jul28153957@crl.crl.com>,
  17. Charles Roten <croten@crl.crl.com> wrote:
  18. : ...
  19. : Oh, yes, before I forget .. I've got rts/cts flow control set up in both 
  20. : C-Kermits, fore-and-aft, in their .kermrc files.  And I've checked both 
  21. : using "show".
  22. :
  23. Remember: In old versions of SunOS, RTS/CTS flow control doesn't work as
  24. expected.  From the ckuker.bwr (C-Kermit for UNIX "Beware" file):
  25.  
  26. "On Sun computers with SunOS 4.0, SET FLOW RTS/CTS works only if the carrier
  27. signal is present from the communication device at the time when C-Kermit
  28. enters packet mode or CONNECT mode.  If carrier is not sensed (e.g.  when
  29. dialing), C-Kermit does not attempt to turn on RTS/CTS flow control.  This
  30. is because the SunOS serial device driver does not allow characters to be
  31. output if RTS/CTS is set (CRTSCTS) but carrier (and DSR) are not present.
  32. Workaround (maybe): SET CARRIER OFF before giving the SET LINE command,
  33. establish the connection, then SET FLOW RTS/CTS."
  34.  
  35. : But when I add in "&k3" to the dialin string I feed C-Kermit 
  36. : on my end, to _force_ my modem to rts/cts flow control, it (again) makes 
  37. : matters _worse_ .. file transfers screwed up in much the same fashion 
  38. : except worse, and sooner)...
  39. :
  40. But we still don't know if your modem is an RPI model or not.  This seems
  41. to suggest that it is.
  42.  
  43. : ... as with 'set dial speed-matching off' ...
  44. :
  45. which (again) has nothing whatever to do with how efficient file transfers
  46. are -- it only tells C-Kermit whether to change its interface speed in
  47. response to the modem's CONNECT message when you first make the call, period.
  48.  
  49. : ... multi-second periods of lockup in interactive throughput (a minute or
  50. : more, in some cases) .. a mess.  _Ignoring_/_not_using_ "&k3" in the dialin
  51. : string makes all these pathologies go away.  _HUH_ ?!?!?
  52. : 
  53. Probably because you are telling the modem to use RTS/CTS flow control
  54. between itself and the Sun, but (if it is an RPI model) it has NO WAY to
  55. pass the flow control upstream to the other modem because there is NO LAPM
  56. OR MNP PROTOCOL between the two modems.  The same applies in the other
  57. direction.
  58.  
  59. There was a long and senseless debate about RPI and similar modems in
  60. comp.dcom.modems about a year ago.  "What happens when some poor soul tries
  61. to use one in a UNIX workstation?"  "Why would anybody do that?" was the
  62. glib answer.  We still don't know for sure that you have an RPI modem -- its
  63. diagnostics are uninformative, you have no documentation...  But it looks
  64. like a duck and it quacks like a duck.
  65.  
  66. There are ways you could find out for sure.  E.g. place a call to (say) a
  67. USR Courier, and then give an ATI6 command to the Courier to see if an
  68. error-corrected connection was negotiated.
  69.  
  70. - Frank